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S!L?£MI]^iG_gQMPUTER SYSTEM AND METHOD WITH 



MULTI-VERSION PROTOCOL COMPATIBILITY 



BACKGROUND OF THE INVENTION 



5 1- Field of the Invention 

The invention is generally related to the storage and 
retrieval of data from streams, and in particular, to a 
manner of supporting multiple versions of a streaming 
protocol . 



2 . Description of Related Art 

Streaming provides a mechanism for the storage and 
retrieval of persistent data in a computer system, or for 
the transmission of data between computer system modules, 
15 whether or not they are within the same computer system. 

With streaming, data is embedded in data streams that follow 
a predetermined streaming protocol to enable a module that 
receives a data stream to reliably decode and retrieve the 
data therefrom. 

20 Many streaming protocols are designed to support the 

transmission of information between modules irrespective of 
their underlying hardware and/or software platforms. This 
is a particular concern with distributed and open computer 
systems, where computing tasks may be broken up and handled 

25 on multiple computers or multiple applications within a 
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computer by passing ob j ects between the computers or 
applications. With distributed systems, e.g., OMG's Common 
Object Request Broker Architecture (CORBA) , IBM's 
Distributed System Object Component (DSOM) , etc., often the 
5 underlying platforms may vary, and a module may not be able 
to direct data to a particular computer, or if it can, may 
not be able to detect the underlying platform of the 
receiving computer. Likewise, a module that formats an 
object for transmission to or use by another module in a 

10 separate application or computer may not be able to detect 

the particular application which will ultimately utilize the 
object, e.g., as with IBM's OpenDoc, Microsoft's Object 
Linking and Embedding (OLE), etc. 

One concern that is raised with respect to such 

15 streaming protocols is that of release-to-release data 
compatibility. In particular, as computer systems and 
applications are upgraded, streaming protocols may likewise 
be upgraded to support enhanced functionality. The upgraded 
computer systems and applications, however, may still be 

20 required to communicate with computer systems and 

applications that only support earlier releases , or 
versions, of a streaming protocol. Likewise, the earlier 
versions may be required to communicate with computer 
systems and applications that support the newer versions. 

25 Since it is often difficult, if not impossible, to detect 
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supported versions of a streaming protocol, some 
incompatibilities may occur. 

Such incompatibilities may be eliminated by upgrading 
all computers and applications in a computer system to 
5 support the same streaming protocol, but this is often not 
feasible due to cost or control issues. 

Therefore, a significant need exists for a manner of 
ensuring release-to-release data compatibility of streaming 
protocols within a computer system. 

10 

SUMMARY OF THE INVENTION 
The invention addresses these and other problems 
associated with the prior art in providing a streaming 
protocol whereby subsequent versions of a protocol are 

15 purely additive relative to earlier versions. When a data 
segment is transmitted as a data stream, a first stream of 
data that is in accordance with a first version of the 
protocol is transmitted, with additional streams of data 
that are in accordance with subsequent versions of the 

20 protocol appended in sequence to the first stream of data. 
A write module that transmits the data stream appends all 
such streams of data up to and including the stream of data 
that is in accordance with the version of the streaming 
protocol implemented by the write module. 
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At the receiving end, a read module receives the first 
stream of data, as well as each additional stream of data up 
to and including that which is in accordance with the 
version of the protocol that is implemented by the read 
5 module. If the end of the data segment is detected prior to 
receiving all of the data expected by the read module 
(indicating that the version of the write module was earlier 
than that of the read module) , the read module will detect 
this and handle the prior version of the data segment 

10 accordingly. Moreover, if the end of the data segment is 

not detected after receiving all of the data expected by the 
read module (indicating that the version of the write module 
was later than that of the read module) , any remaining data 
in the data segment is disregarded. Consequently, forward 

15 and backward compatibility between streaming protocol 
versions are concurrently supported. 

These and other features, which characterize the 
inverjtion, are set forth in the claims annexed hereto and 
forming a further part hereof. However, for a better 

20 understanding of the invention, and of the various 

advantages and objectives attained by its use, reference 
should be made to the Drawing, and to the accompanying 
descriptive matter, in which there is described illustrated 
embodiments of the invention. 
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BRIEF DESCRIPTION OF THE DRAWINGS 
Referring now to the Drawings in which like reference 
numbers represent corresponding parts throughout: 

FIG. 1 is a block diagram of an exemplary hardware 
5 environment for use with the illustrated embodiments of the 
invention; 

FIG. 2 is a block diagram illustrating the transmission 
of a data stream between write and read modules consistent 
with the principles of the present invention; 
10 FIG. 3 is a flowchart of a WriteToStream routine 

consistent with the principles of the invention; 

FIG. 4 is a flowchart of a ReadFromStream routine 
consistent with the principles of the invention; 

FIG. 5 is a block diagram of an exemplary data stream 
15 consistent with the invention; and 

FIG. 6 is a block diagram of another exemplary data 
stream consistent with the invention. 



DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS 
20 In the following description reference is made to the 

accompanying drawings which form a part hereof^ and which is 
shown by way of illustration, embodiments of the invention. 
It is understood that other embodiments may be utilized and 
structural changes may be made without departing from the 
25 scope of the present invention. 
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Hardware Environment 

FIG. 1 is an exemplary hardware environment used to 
implement an illustrated embodiment of the invention. The 
present invention is typically implemented in a computer 
5 system 5 which may include one or more computers 10, e.g., 
in a stand-alone environment, or, as shown in FIG. 1, in a 
connected network 8. For example, it is over network 8 that 
data streams may be passed between each computer 10. 
Network 8 may be, for example, a LAN, a WAN, or a public 

10 network such as the Internet. 

It is envisioned that attached to each of computers 10 
may be a monitor 14 (e.g., a CRT, an LCD display or other 
display device); and non-volatile storage 16 (e.g., hard, 
floppy, and/or CD-ROM disk drives) . Also included may be 

15 various input devices, for example, a keyboard 12. 

Generally, the computer programs (illustrated at 20) 
which implement the illustrated embodiments of the invention 
are tangibly embodied in a computer-readable medium, e.g., 
one or more of the fixed and/or removable data storage data 

20 devices 16. Under control of computer 10, the computer 

programs may be loaded from the data storage devices 16 into 
the memory of computer 10. The computer programs comprise 
instructions which, when read and executed by computer 10, 
cause computer 10 to perform the steps necessary to execute 

25 the steps or elements of the present invention. 



6 



ST9-96-505 




Those skilled in the art will recognize that the 
exemplary environment illustrated in FIG. 1 is not intended 
to limit the present invention. Indeed, those skilled in 
the art will recognize that other alternative hardware 
5 environments may be used without departing from the scope of 
the present invention . 

Software Implementation 

The illustrated embodiments of the invention generally 

10 provide release-to-release data compatibility over multiple 
versions of a streaming protocol by requiring version 
modifications to the streaming protocol to be purely 
additive, so that a data stream output in accordance with a 
streaming protocol includes data segments sequenced 

15 according to each version of the streaming protocol up to 
and including the version implemented in the write module 
outputting the data stream. A read module which receives 
the data stream includes forward compatibility by 
disregarding any data related to later versions after all of 

20 the data up to and including the version of the module has 
been received. Backward compatibility is provided by 
detecting premature end tags and handling the unreceived 
data accordingly . 

As shown in FIG. 2, illustrated embodiments of the 

25 invention are generally implemented in write modules, such 



7 



ST9-96-505 



as write module 22, which output a data stream, and read 
modules, such as read module 24, which receive the data 
stream. It should be appreciated that the read and write 
modules may be software objects or components having one or 
more methods or routines that implement the functionality of 
the modules, and that the modules may be resident on the 
same computer, e.g., in different computer programs or 
applications that may communicate via streaming (as in 
OpenDoc and OLE) . Moreover, the read and write modules may 
be resident on different computers within a networked 
computer system (e.g., in a distributed computer system such 
as DSOM or CORBA) . Furthermore, the read and write modules 
need not be implemented on the same hardware and/or software 
platform (e.g., where a write module is implemented on a 
UNIX platform and a read module is implemented on a PC 
platform) . 

Data streams consistent with the invention are 
typically tag-delimited and may include data segments which 
represent objects and/or primitive data types. In addition, 
aliasing may be supported, whereby special information is 
written to the data stream to enable reconstruction of 
aliased pointers in the event that multiple pointers refer 
to the same data. 

The data streams may be more or less serial, where all 
of the information required to reconstruct an object from a 
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data segment is stored within the data segment. 
Consequently, no additional information, e.g., a separate 
database, need be streamed out at the end of a data stream 
as is required with some conventional streaming methods. 
Moreover, the data streams need not be random access 
streams, although random access streams may also be 
supported. 

The data streams are output by write modules in formats 
that are dictated by a streaming protocol which may be 
revised from time to time, thereby forming a plurality of 
versions of the streaming protocol. Consistent with the 
invention, revisions to the streaming protocol are purely 
additive, and are appended to one another in sequence. For 
example, FIG. 2 illustrates a data stream having a data 
segment 26 which includes, in sequence, streams of data 
according to versions 1 to n of a streaming protocol. 

A write module may be considered to implement a 
particular version of a streaming protocol when the write 
module outputs data in the format dictated by that version 
of the streaming protocol. Likewise, data streams are 
received by read modules which expect the data to be 
formatted according to particular versions of a streaming 
protocol. A read module may therefore be considered to 
implement a particular version of a streaming protocol when 
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the read module expects to receive data in the format 
dictated by that version of the streaming protocol. 

FIG. 3 illustrates a WriteToStream routine 50 for 
execution by a write module to stream out a data segment 
5 (here, a particular object) comprising a sequence of streams 
of data. For illustrative purposes, routine 50 may be 
considered to implement a version n of a streaming protocol . 
A corresponding ReadFromStream routine 100, which implements 
a version m of the streaming protocol is shown separately in 

10 FIG. 4. Routine 50 supports object aliasing, whereby 

subsequent references to objects that have been written to a 
stream may be replaced by alias tags, rather than writing 
additional copies of the object to the stream. However, it 
should be appreciated that support for aliasing may be 

15 omitted in some applications. 

Routine 50 outputs a tag-delimited data stream whereby 
object data is preceded by a begin tag and followed by an 
end tag. In addition, alias tags are also used to point to 
the location of information in the data stream that is being 

20 aliased. Each tag may include an identifier field for 
identifying the type of tag, e.g., begin tag, end tag, 
object type tag, object alias tag, object type alias tag, 
etc. Each tag may also include a pointer field that points 
to another location in the data stream. Other tag formats 

25 may be used in the alternative. 
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Routine 50 begins in block 52 by determining whether an 
object type for the object, typeinfOy is stored in the 
current context. Typeinfo provides an object type for the 
object so that the object may be allocated and initialized 
(e.g., by calling an appropriate default constructor) to 
recreate the object. The current context is an object that 
maintains a record of the objects and object types therefor 
that have been written to a data stream. Each entry in the 
current context preferably includes an object type for the 
object, as well as a pointer to the location of the data in 
the data stream. It should be appreciated that the current 
context may be initialized in a separate routine, or in the 
alternative, routine 50 may initialize the current context 
if the routine determines that this has not been so done. 

If the object type is not in the current context, the 
object type is saved in the current context in block 54, 
then the object type tag is written to the stream. If, on 
the other hand, the object type is in the current context, 
an alias tag is written to the stream in block 58. The 
pointer for the alias tag includes the byte offset in the 
data stream to the object type being referenced by the alias 
tag . 

Next, in block 60, routine 50 determines whether the 
object itself is in the current context. If it is, then an 
alias tag, which points back to the first instance of the 
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object in the data stream, may be written to the stream in 
block 62f whereby no further processing is required. The 
alias tag may be configured similar to the alias tag for the 
object type, with the pointer for the alias tag including 
5 the byte offset in the data stream to the object data being 
referenced thereby . 

If;, on the other hand, the object is not stored in the 
current context, the object is saved in the current context 
in block 64. Next, in block 64, a begin tag is written to 
10 the stream to delimit the start of the data for the object. 
The pointer for the begin tag may include, for example, the 
byte offset in the data stream to the matching end tag for 
the object. 

Next, in block 68, all of the data for the object in 
15 accordance with the earliest (first) version of the 

streaming protocol is written to the stream in block 68. 
Any additional data for the obj ect that is supported by 
subsequent versions of the streaming protocol up to and 
including the version n being implemented by routine 50 is 
20 thereafter appended to this data, as shown by blocks 70-72, 
Data for each version may be appended sequentially in order 
from earliest to latest version, with the current version 
implemented by the routine coming last in the data stream. 
Each separate piece of data, for example, primitive 
25 fields, does not require tagging. Only version tags are 
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required- This provides significant savings in stream 
storage as well as higher read performance. Moreover, 
information to support polymorphic streaming only need be 
emitted when necessary. The source write operation may 
5 determine the type of the object and compare it to the type 
of pointer. Information necessary to support a polymorphic 
read operation need only be stored in the stream if the type 
of object and the type of pointer are different. This 
represents very substantial savings in storage, write 

10 performance and especially read performance. 

Once all of the data for the object is written to the 
data stream, the end tag, which matches the begin tag 
written in block 66, is written to the data stream in block 
74. The pointer for the end tag generally includes the byte 

15 offset to the next tag in the data stream. After the end 
tag is written to the data stream, streaming of the object 
is complete . 

It should be appreciated that routine 50 as shown in 
FIG. 3 is merely a template for streaming out a generic 

20 object, and thus may be provided in a framework or class 

library and modified by a programmer to tailor the routine 
depending upon the particular data structure of an object to 
be streamed out. Typically, blocks 68-72 of routine 50 are 
customized to stream out suitable object data for a specific 

25 object to the data stream. In practice, the object data may 



13 



ST9-96-505 




vary greatly depending upon the particular object being 
written;, as well as the version of the streaming protocol 
being used to stream out the object. 

FIG. 4 illustrates a corresponding ReadFromStream 
5 routine 100 for execution by a read module to read in the 

data segment (here, an object) written to the data stream by 
routine 50. For illustrative purposes^, routine 100 may be 
considered to implement a version m of a streaming protocol. 
Routine 100 begins at block 102 by reading the object 

10 type typeinfo from the data stream. Next, it is determined 
whether the object type is an alias tag in block 104 . If it 
is, control passes to block 106 to retrieve the object type 
from the current context. If it is not, control passes to 
block 108 to save the object type in the current context. 

15 As with routine 50, it may also be necessary to initialize 
the current context if not previously so done . 

In either event, control next passes to block 110 to 
read the next tag from the data stream. Next, it is 
determined in block 112 whether this tag is an alias tag. 

20 If it is, then control passes to block 116 to retrieve from 
the current context the pointer to the previously-created 
object referenced by the alias tag, whereby retrieval of the 
obj ect is then complete . 

Otherwise, control passes to block 114 to allocate and 

25 initialize the object by calling the default constructor for 
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the object based upon its object type received from either 
the data stream or the current context. As noted above, the 
default constructor is the program code that forms a 
template for how to build an object from the forthcoming 
data in the data stream. It is the default constructor 
which typically defines what version of a streaming protocol 
is supported, since the default constructor expects to 
receive object data in a predetermined format. Other 
manners of allocating and initializing the object may be 
used in the alternative . 

Next, control passes to block 118 to read the object 
data according to the first version of the streaming 
protocol from the data stream. At this time, the data is 
also used to build the object based upon the template 
provided by the default constructor. 

Next, in block 120, it is determined whether the end of 
the object has been detected, typically by checking if an 
end tag is received when it is not expected. If so, this 
indicates that an earlier version of the streaming protocol 
was used to stream out the object data (i.e., n < m) . In 
this case, control passes to block 122 to initialize (e.g., 
set to null or another default value) all of the object data 
according to each subsequent version of the streaming 
protocol (up to and including the version m implemented by 
routine 100) . It may also be necessary to include suitable 
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program code in any other routines that handle the object to 
detect and specially handle the default values. Upon 
completion of initializing the object data, control passes 
to block 134 to save the object in the current context, 
whereby streaming in of the object is complete. 

Returning to block 120, if the end of the object is not 
detected, blocks 124-130, which are similar in operation to 
blocks 118-122, read in the object data according to the 
subsequent versions of the streaming protocol up to version 
m implemented by routine 100. Also, between reading in the 
object data according to each subsequent, premature ends of 
blocks are detected in order to maintain backward 
compatibility and initialize any object data not supplied in 
the data stream. 

Forward compatibility is provided by block 132, which 
skips to the end tag for the object in the data stream if 
the end tag has not yet been reached after reading in the 
object data according to version m of the streaming protocol 
(which typically occurs when n > m) . Thus, any object data 
supplied for later versions of the streaming protocol is 
disregarded in building the object. However, any skipped 
data may be stored in the current context for later 
retrieval, e,g., as required for aliasing. Control then 
passes to block 134 to save the ob j ect in the current 
context, whereby streaming in of the object is complete. 



ST9-96-505 




It should be appreciated that routine 100 is a general 
template for a streaming routine which does not implement a 
first version of a streaming protocol (i.e., m > 1). To use 
this routine as a template for implementing a first version 
5 of a streaming protocol, blocks 120-130 may be omitted, 
given that the receipt of premature end tags is generally 
not a concern. 

To illustrate the operation of routines 50 and 100 in 
providing forward and backward compatibility, two versions 

10 of a streaming protocol that is implemented as a streamable 
class Apple are set forth in Tables I and II below. The 
object data for the first version of Apple includes the 
instances of two objects: Orange and Banana. The object 
data for the second version of Apple includes a second 

15 instance of the Banana class, fExtBanana . This additional 
object data is appended in the data stream following the 
instances of Orange and Banana, 

The Apple class is a polymorphically streamable C++ 
class. The Orange and Banana classes, which are utilized by 

20 the Apple class, are also polymorphically streamable C++ 
classes; however, the details of these classes are not 
important for an understanding of the invention. 
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class Apple { 
public: 



virtual void wrlteToStream (IDataStreamSc toWhere) const; 
virtual void readFromStream (lDataStream& fromWhere) ; 



private: 

Orange ^^f Orange ; 



}; 

void 



} 

void 



Banana "^f Banana ; 

Apple: :wrlteToStream (IDataStream& toWhere) const { 
IStreamOutFrame myStreamOutFrame ; 
fOrange~>wrlteToStream (toWhere) ; 
fBanana~>wrlteToStream (toWhere) ; 

Apple: : readFromStream (lDataStream& fromWhere) { 
IStreamIn Fram e myS t ream In Fram e ; 
fOrange->readFromStream (fromWhere) ; 
fBanana->readFromStream (fromWhere) ; 



Table I: First Version of Streaming Protocol 
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class Apple { 
public: 

virtual void writeToStream (IDataStream& toWhere) const; 
virtual void readFromStream (lDataStream& fromWhere) ; 

private: 

Or an ge "^f Orange ; 
Banana ^^f Banana; 
10 Banana "^fExtBanana; 

}; 

void Apple: : writeToStream (IDataStream& toWhere) const { 
IStreamOutFrame myS treamOut Frame ; 
fOrange~>writeToStream (toWhere) ; 
15 fBanana->writeToStream ( toWhere) ; 

fExtBanana->writeToStream (toWhere) ; 

} 

void Apple :: readFromStream (IDataStreama fromWhere) { 
IS t ream In Fram e myS t ream In Fram e ; 
2 0 fOrange~>readFromStream (fromWhere) ; 

fBanana->readFromStream (fromWhere) ; 
if ( ! myStreamlnFrame , a tEnd () ) 

fExtBanana->readFromStream (fromWhere) ; 

else 

25 fExtBanana = NULL; 

} 



Table II: Second Version of Streaming Protocol 
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The writeToStream method for each version of the Apple 
class generally represents the object data writing steps 68- 
72 of routine 50. Similarly;, the readFromStream method for 
each version of the Apple class generally represents the 
object data reading steps 118-130 of routine 100. 

Backward compatibility may be illustrated by streaming 
out a first version of Apple and streaming in the second 
version of Apple, Suitable code for streaming out Apple is 
illustrated below in Table III below: 



15 



IDataStream^ myDataStream = , . . 

Apple'^ myApple = new Apple (); 

myApple~>wrlteToStream ("^myDataStream) ; 



Table 111: Stream Out Code ~ Backward Compatibility 



The format of the data stream generated by the above 
20 code is illustrated by data stream 40 in FIG. 5^ whereby 

pointers from each tag are represented by arrows pointing to 
the targets of the pointers. It is assumed that none of 
Appier Orange, and Banana have previously been output to the 
data stream, and thus, no aliasing is utilized when 
25 outputting the object data for Apple. As discussed above in 
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relation to routine 50 of FIG. 3, when no aliasing occurs, 
the general output to a data stream includes an object type 
tag, a begin tag, the object data, and an end tag- 
Referring to the first version of the Apple class in 
5 Table I, the object data for the first version of Apple 

includes Orange and Banana^ and thus the two WriteToStream 
calls made in the WriteToStream method in the Apple class 
correspond generally to block 68 of routine 50 (FIG. 3) . 
Moreover, since this is the first version of the Apple 

10 class, blocks 70-72 are omitted. Each of Orange and Banana 
also output data in the same general manner as routine 50, 
and thus the object data portion of the data stream for 
Apple includes an object type tag, a begin tag, object data, 
and an end tag for both Orange and Banana, 

15 Streaming in of the data stream of FIG. 5 follows the 

general program flow of routine 100 of FIG. 4. Here, the 
statements in the readFromStream method of Table II 
correspond generally to blocks 118-124 of routine 100, with 
blocks 126-130 omitted since this is the second version of 

20 the Apple class. Here, since the readFromStream method for 
the second version of the Apple class receives the end tag 
for Apple prior to receiving any fExtBanana object, this 
ob j ect is initialized to null . 
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Forward compatibility may be illustrated by streaming 
out a second version of Apple and streaming in the first 
version of Apple, Suitable code for streaming out the 
second version of Apple is illustrated below in Table IV 
5 below. Moreover, to illustrate aliasing, the streaming out 
of an additional instance of Banana is performed following 
Apple. 



10 
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IDataStream' 
Banana 



myDataStream = . . . 
myApple =^ new Apple (); 
myBanana = new Banana (); 



myBanana = myApple . fExtBanana ; 

myApple ->wrlteToSt ream ( "^myDataStream) ; 
myBanana ->wrlteToSt ream (^^myDataStream) ; 



Table IV: Stream Out Code ~ Forward Compatibility 



20 The format of the data stream generated by the above 

code is illustrated by data stream 45 in FIG . 6 , with 
pointers from each tag represented by arrows pointing to the 
targets of the pointers. Referring to the second version of 
the Apple class in Table I, the object data for the first 

25 version of Apple includes Orange and Banana^ and thus the 
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first two WriteToStream calls made in the WriteToStream 
method in the Apple class correspond generally to block 68 
of routine 50 (FIG. 3) . The data according to the second 
version of the streaming protocol, fExtBanana ^ is streamed 
5 out after Orange and Banana ^ and thus, the last 

WriteToStream call made in the WriteToStream method in the 
Apple class corresponds generally to block 70 of routine 50. 

Also, as may be seen from the data stream of FIG. 6, 
when fExtBanana is streamed out, the object type therefor is 
10 already stored in the current context as a result of 

streaming out f Banana . Consequently, an alias tag for the 
fExtBanana object type is streamed out instead the object 
type itself . 

As an illustration of aliasing, after Apple is streamed 
15 out, myBanana is streamed out. Since both the object type 
and the object itself have been streamed out with Apple, 
both are stored in the current context. Thus, when myBanana 
is streamed out, alias tags for the object type and the 
object are output to the data stream in lieu of the actual 
20 obj ect data . 

Streaming in of the data stream of FIG. 6 also follows 
the general program flow of routine 100 of FIG. 4. Here, 
the statements in the readFromStream method of Table I 
correspond generally to block 118 of routine 100, with 
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blocks 120-130 omitted since this is the first version of 
the Apple class. When the object data for Apple is read in^ 
only Orange and Banana (the data according to the first 
version of Apple) are read in. The readFromStream method 
5 terminates^ and the remaining object data in Apple is 

disregarded (see block 132 of FIG. 4). This is implemented 
in the Apple class by virtue of IStreamlnFrame being a 
scoped object whose scope ends after Banana is streamed in. 
A destructor method (not shown) is called when the scope of 

10 IStreamlnFrame ends to skip to the end of Apple. 

Consequently, for data stream 45, the object data between 
the Banana end tag and the Apple end tag may be disregarded 
and skipped, thereby providing forward compatibility for the 
Apple class. This data may, however, be stored in the 

15 current context for retrieval by aliased obj ects . 

For streaming in the aliased myBanana after streaming 
in Appier the alias tags for the Banana object type and the 
Banana object itself are read, and then the object type and 
object data are read out from the current context (i.e., as 

20 shown by blocks 108 and 116 of routine 100 in FIG. 4) . 
Streaming in of data stream 45 is then complete . 

Various modifications may be made to the illustrated 
embodiments without departing from the spirit and scope of 
the invention. For example, other actions may be taken than 
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initializing object data to a null or other default value 
when reading a data stream generated according to an earlier 
version of the streaming protocol. 

Other modifications will be apparent to one skilled in 
5 the art. Therefore, the invention lies solely in the claims 
hereinafter appended . 
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WHAT IS CLAIMED IS: 

1. A method of transmitting a data segment in a data 
stream using a write module of the type which implements a 
selected one of a plurality of versions of a streaming 
5 protocol, the method comprising the steps of: 

(a) outputting a first stream of data according to a 
first version of the streaming protocol; and 

(b) sequentially appending additional streams of data 
to the first stream of data according to each subsequent 

10 version of the streaming protocol up to and including the 
selected version, if the selected version of the streaming 
protocol is not the first version of the streaming protocol. 



2. The method of claim 1, further comprising the step 
15 of receiving the data segment from a data stream using a 

read module of the type which implements a second selected 
one of the plurality of versions of the streaming protocol, 
the receiving step including the steps of: 
receiving the first stream of data; 
20 if the second selected version is earlier than the 

first selected version, receiving each additional stream of 
data according to each subsequent version of the streaming 
protocol up to and including the second selected version, 
and disregarding any remaining data in the data segment; 
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if the second selected version is equal to or later 
than the first selected version, sequentially receiving the 
additional streams of data according to each subsequent 
version of the streaming protocol up to and including the 
5 second selected version; and 

testing, prior to receiving each additional stream of 
data, whether an end of the data segment has been detected, 
and if so, terminating reception of the data segment prior 
to receiving the additional stream of data according to the 
10 second selected version. 

3. The method of claim 2, wherein the data segment is 
an object. 

15 4. The method of claim 3, wherein the data segment 

includes all of the data necessary to reconstruct the 
object; wherein the data stream is serial. 

5. The method of claim 3, wherein the testing step 
20 includes the step of initializing object data that is not 

received from the data stream to a default value . 

6. The method of claim 3, further comprising the 
steps of : 

25 transmitting an object type for the data segment; and 
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receiving the object type, including the steps of 
allocating and initializing an object when receiving the 
data segment based upon the object type. 

5 7. The method of claim 2, wherein the read and write 

modules are resident on the same computer. 

8. The method of claim 2, wherein the read and write 
modules are resident on separate computers. 

10 

9. The method of claim 1, further comprising the step 
of delimiting the data segment in the data stream using 
begin and end tags . 

15 10. The method of claim 9, wherein no additional tags 

are embedded in the data segment between the begin and end 
tags . 



11. The method of claim 1, further comprising the 
20 steps of: 

determining whether the data segment is stored in a 
current context for the data stream; 

if so, transmitting an alias tag in lieu of the data 
segment; and 
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if not, storing the data segment in the current 
context . 

12. The method of claim 1, wherein the data stream is 
a non-random access data stream. 

13- A method of receiving a data segment from a data 
stream using a read module of the type which implements a 
selected one of a plurality of versions of a streaming 
protocol, the method comprising the steps of: 

(a) receiving a first stream of data according to a 
first version of the streaming protocol ; 

(b) if the selected version of the streaming protocol 
is not the first version of the streaming protocol, 
sequentially receiving additional streams of data according 
to each subsequent version of the streaming protocol up to 
and including the selected version; and 

(c) testing, prior to receiving each additional stream 
of data, whether an end of the data segment has been 
detected, and if so, terminating reception of the data 
segment prior to receiving the additional stream of data 
according to the selected version. 

14, The method of claim 13, further comprising the 
step of disregarding any remaining data in the data segment, 
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if the end of the data segment has not been detected upon 
receiving the additional stream of data according to the 
selected version. 



5 15. The method of claim 14^ further comprising the 

step of storing the data segment in a current context, 
including any disregarded data therefrom. 



16. The method of claim 13, wherein the data segment 
10 is an object. 



17. The method of claim 16, wherein the testing step 
includes the step of initializing object data that is not 
received from the data stream to a default value. 

15 

18. The method of claim 16, further comprising the 
steps of: 

receiving an object type for the data segment; and 
allocating and initializing an ob j ect based upon the 
20 object type to build the object from the streams of data in 
the data segment. 



19. A computer system that transmits data segment in a 
data stream, the computer system comprising a write module 
25 that implements a selected one of a plurality of versions of 
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a streaming protocol, and that outputs the data segment in 
the data stream, wherein the write module comprises: 

(a) means for outputting a first stream of data 
according to a first version of the streaming protocol; and 



streams of data to the first stream of data according to 
each subsequent version of the streaming protocol up to and 
including the selected version, if the selected version of 
the streaming protocol is not the first version of the 
10 streaming protocol . 

20. The computer system of claim 19, wherein the data 
segment is an object. 

15 21. The computer system of claim 19, wherein the write 

module further comprises means for transmitting an object 
type for the data segment. 

22. The computer system of claim 19, wherein the write 
20 module further comprises means for transmitting begin and 

end tags to delimit the data segment in the data stream. 

23. The computer system of claim 19, wherein the write 
module further comprises means for transmitting an alias tag 



(b) 



means 



for sequentially 



appending 



additional 



ST9-96-505 



in lieu of the data segment if the data segment is stored in 
a current context for the data stream. 



24, A computer system that receives a data segment 
5 from a data stream^, the computer system comprising a read 
module that implements a selected one of a plurality of 
versions of a streaming protocol^ and that receives the data 
segment from the data stream^ wherein the read module 
comprises : 

10 (a) means for receiving a first stream of data 

according to a first version of the streaming protocol; 

(b) means for sequentially receiving additional 
streams of data according to each subsequent version of the 
streaming protocol up to and including the selected version^ 

15 if the selected version of the streaming protocol is not the 
first version of the streaming protocol ; and 

(c) means for testing whether an end of the data 
segment has been detected, and if so, for terminating 
reception of the data segment prior to receiving the 

20 additional stream of data according to the selected version 
prior to receiving each additional stream of data , 



25. The computer system of claim 24, wherein the read 
module comprises means for disregarding any remaining data 
25 in the data segment, if the end of the data segment has not 
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been detected upon receiving the additional 
according to the selected version. 



stream of data 



26. The computer system of claim 24^ wherein the data 
segment is an ob j ect . 



27. The computer system of claim 26, wherein the read 
module comprises means for receiving an object type for the 
data segment, and for allocating and initializing an object 
based upon the object type to build the object from the 
streams of data in the data segment , 



28. A computer system comprising first and second 
computers that transmit a data segment in a data stream from 
the first computer to the second computer, the first 
computer comprising means for implementing a first selected 
one of a plurality of versions of a streaming protocol, and 
the second computer comprising means for implementing a 
second selected one of the plurality of versions of the 
streaming protocol, wherein : 

(a) the first computer includes a write module for 
transmitting the data segment, wherein the write module 
outputs a first stream of data according to a first version 
of the streaming protocol, and if the first selected version 
is not the first version of the streaming protocol, the 
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write module sequentially appends to the first stream of 
data additional streams of data according to each subsequent 
version of the streaming protocol up to and including the 
first selected version; and 
5 (b) the second computer includes a read module for 

receiving the data segment from the first computer, wherein 
the read module receives the first stream of data, wherein 
if the second selected version is earlier than the first 
selected version, the read module receives each additional 

10 stream of data according to each subsequent version of the 
streaming protocol up to and including the second selected 
version, and disregards any remaining data in the data 
segment, wherein if the second selected version is equal to 
or later than the first selected version, the read module 

15 sequentially receives the additional streams of data 
according to each subsequent version of the streaming 
protocol up to and including the second selected version, 
and wherein, prior to receiving each additional stream of 
data, the read module detects whether an end of the data 

20 segment has been detected, and if so, terminates reception 

of the data segment prior to receiving the additional stream 
of data according to the second selected version . 

29. A program storage device, readable by a computer 
25 system and tangibly embodying one or more programs of 
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instructions executable by the computer system to perform 
method steps of transmitting a data segment in a data stream 
in a format based upon a selected one of a plurality of 
versions of a streaming protocol;^ the method comprising the 
5 steps of: 

(a) outputting a first stream of data according to a 
first version of the streaming protocol; and 

(b) sequentially appending additional streams of data 
to the first stream of data according to each subsequent 

10 version of the streaming protocol up to and including the 
selected version, if the selected version of the streaming 
protocol is not the first version of the streaming protocol. 



15 system and tangibly embodying one or more programs of 

instructions executable by the computer system to perform 
method steps of receiving a data segment from a data stream 
according to a selected one of a plurality of versions of a 
streaming protocol, the method comprising the steps of: 

20 (a) receiving a first stream of data according to a 

first version of the streaming protocol ; 

(b) sequentially receiving additional streams of data 
according to each subsequent version of the streaming 
protocol up to and including the selected version, if the 
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selected version of the streaming protocol is not the first 
version of the streaming protocol; and 

(c) testing, prior to receiving each additional stream 
of data, whether an end of the data segment has been 
detected, and if so, terminating reception of the data 
segment prior to receiving the additional stream of data 
according to the selected version. 
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ABSTRACT OF THE DISCLOSURE 



A forward and backward compatible streaming protocol 
requires subsequent versions of the protocol to be purely 
additive relative to earlier versions. When a data segment 
is transmitted as a data stream^ a first stream of data that 
is in accordance with a first version of the protocol is 
transmitted, with additional streams of data that are in 
accordance with subsequent versions of the protocol appended 
in sequence to the first stream of data. When a read module 
implements an earlier version of the protocol than a write 
module, the data segment is truncated to include only the 
data supported by the version implemented by the read 
module. On the other hand, when the read module implements 
a later version of the protocol than the write module, 
receipt of the data segment is terminated after the data 
supported by the version implemented by the write module is 
received . 




4 hereby ceriify i*^BX this paper or fee Is t>e*ng de- 



posited whh the Untied States Postal Service "Express 
Ma'tf Post Off'ce ro Addressee" serv'tce under 37 CFR 
1,10 on the date ind'tcaTcd above and Is addressed to: 



Assistant Commissioner ior Patents. Washmgton. O.C 2023t» 




ST9-96-505 




26 



1 



version 1 


version 2 


• • • 


version n 




Fig. 2 



Apple 
typeinfo 



Apple 
Begin Tag 



Orange 
typeinfo 



Orange 
Begin Tag! 



Orange 
Data 



Orange 
End Tag 



Banana 
typeinfo 



Banana 
Begin Tag! 



Banana 
Data 



Banana 
End Tag 



Apple 
End Tag 



AO 



Fig. 5 



50 
52 




Write ToStream 
(version n) 

Object 
typeinfo in current^ 
context? 



54 



no 



58 



yes 



Fig. 3 



I 



z 



Save object 
typeinfo in 
current context 



Write alias for 
object typeinfo 
to stream 



60 




Write object 
typeinfo to 
stream 



.56 



Object 
in current 
context? 



yes 



64. 



66 



no 



Save object in 
current context 



Write begin tag 
to stream 



68. 



70 



Write version 1 object 
data to stream 



Write version 2 object j 
data to stream | 



72, 



Write version n object [ 
data to stream i 



74. 



Write end tag 
to stream 



Done 



62 



Write alias for 
object to stream 



ReadFromStream (version m) | 

100 -T- ^ 

t _ 



106 



Retrieve object 
type info from 
current context 



yes 



Read object typeinfo 
from stream 



"^Object typeinfo 
an alias? 



104 



Fig. 4 



110. 



112 




108 



Save object 
typeinfo in 
current context 

1 



Read next tag 
from stream 



116 




^ G^t pointer to object 

from current context 



114_ 



118. 



Alias tag? 



L 



Call default 
constructor for object 



122 



Read version 1 object 
data from stream 



Set version 2 yes><T — — x 1 

torn object .jHrK"^?V 
data to null ^^\£bject?y 



20 



'^nc 



128 



Read version 2 object 
data from stream 



.124 



1 >^ 

I Set version 3 , yes r: -▼- 
' r» i^/At end of\ 

- ton? object obiect? 
, data to null , x°°J!.^L- / 



.126 



130 



[ Read version m object , 
i data from stream , 

3L 



Skip to end tag 
in stream 



5 



Save object in 
current context 



[ Done ] 



132 



134 



Apple 
typeinfo 



Apple 
Begin Tag 



Orange 
typeinfo 



Orange 
Begin Tag 



Orange 
Data 



Orange 
End Tag 



Banana 
typeinfo 



Banana 
Begin Tag 



Banana 
Data 



Banana 
End Tag 



Alias to Banana 
typeinfo 



ExtBanana 
Begin Tag 



ExtBanana 
Data 



ExtBanana 
End Tag 



Apple 
End Tag 



Alias to Banana 
typeinfo 



Alias to Banana 
Data 



45 



Fig. 6 





Page i o£ 3 



OBCXAXATXaN MSD POMHR OF kSTOKOSSt FOR PATSHT APPXiZCAXX<m 



AS a below uamod invtntor, I hereby declare thilit: 



My reaidenocr post office addreea *nd citi»ettBhip a« b«low next to .^ly name 7 

I believe I am tba ortglWtl* first and sole inventor (if only one sanifi is liii;>a b^low) or 
an priginal, first and joint inventor (if pluawil names are listed below) of t>3 subject 
tttatter which Is oi«jlin»a AOid for wh-trh m pntant i» fsnng-)!!: cm hha invAAtinn ^n^^' --Aed 



tMt specification of which (check one} 

^ ie attetched hereto, 

was filed on 

as Jtoplieati^ Serial No^ 

and wa» amended on ^ (if applicable) , 

t hereby &tat« that 1 have nviewed ^d u^^rtftAAd tha eonteate Of the above i:aentif ied 
specif ioatioiTi/ iAOlttdixig the cXaitas^ as am end ed by any a men d m ent referred to s,^zov^, 

Z aoknowlftdga the duty to discloee information which is material to patentability as defined 
in Title 37, code of Federal Regulations, Section 1.56. 

I hereby claim foreign priority benefits under iritle 35. ^Jhited fitatee Code, .-^•^ctiQn 1X9 of 
any Coreign asplioation(a) for patent or inventor' e certificate lleted below cind have also 
identified below any foreign application for patent or inventor's certificate having a 
filing date before that of the application on which priority is claimed: 

Prior Foreign Jipplication(s) Priority Claimed 



X hereby cia&m the benecit under Title 35, xmited states codOi section i2o of —y tThited 
Stacea application (a) listed below and. ineofar as the subject matter of each c * the elaim» 
of this applioation is not disclosed in tbe prior tinited Statea application ii*: the manner 
provided by the first paragraph of Title 35, Uhited State* Code. Section Z acknowledge 
the duty to disclose information which is TMtterial to patentability as defir-ed in Title 37, 
Code of Federal Regulations, Section 1*56* v^ch occurred between the filing dcLte of the 
prior application and the national or PCT infcernaticmal filing date of this ftr^^^lication: 



CJS^licatiOtt Serial Wo.) (Filing oate) " ' (statusT Tj^tehted, pendirjcr, abandoned) 

I hereby declare that all statements made herein of my own knowledge are true ,-*.nd that all 
Stateocumte made on infonoation and belief are believed to be true; and furtJtier that these 
statements were made with the icnowledge that willful false statenents and the liKO SO made 
are punishable by fine or iir^isonment; or both, under section lOOl of Title 13 of the 
united States code and that such willful false statesnents may jeopardize the v.-ilidity of the 
application or any patent issued thereon. 



{Nundxsr} 



(Country) 



(Day/Month/Year Filed) 



^NO 



WWKR OF ATTOBHBYi A« » n«i»d inv«xtor, Z n^ra&y appoint th« followinjr attonijty (a> and/or 
Ag«nt{fi) to proeecure thiff ftW?li«3itioa aiui transact All businoM in the P»t«trn ^inu Tradamark 
0«ic« conn^ct^d tbarawitli, {l±9t name axu) xagiatration number) 

M^rilYTi Smith Dawkina, Hegiatration Wo. aoJAft. glfflf^^*^^? A Iftj^yp R«gi5^r'=^.iOT Vq. 

g ^ffl l^i^ffg ff, jrp ^n; ^fiy«^ . Ho^iatration No. 3a. 123. sdvard^A^aiminqton. Raglstratlcn Ko. 3?i?Sg/ 
Joaaph C. Racgmond, Jr, , Regiatratiott t*o, lg>753 . all of whom are attomaya wiv.;i iSM 
Corporatioa; a&d 

Gteorge H. Gates . ji«gi»tMtion No- 11.500. Gr«TQrv B. wood. Ragiatration NO. 23jJ^^, Eamsofl 
Ai. BQcnigHA. Registration HO* and aaElSfc-ESJCBSa^ Ragijtratioa »0- i^JLiS. all 

whom are attomeya with the law firm of Merchaat, Gould, Smxth, Sdall, Walter ^ Soiinadt 

sand correspondeaca toi George R. Gatea, Eaq. 

Mar«bant, eould, Smith, Edell, 

Welter & Schmidt 
Suite 400 

1X150 Santa Monica Boulevard 

Los Angalea, Calif wnia &Q02$-Aa$5 

Diraot Tttlaphooa Calla tet (name and telephooa number} Oacx9* K. OatM. (310) 145-1140 



Full sMOM Of aola or firat joint '^iztvantox?} Mark 1. Mvla 



Rasidance: 2503 Ali^i^e Road# Kania Far^c, California 9402SCL^ 



Citizenship ; v » S • A * 



Foat office Addreaa; Ssss 



toll XMme of aaeond ;ioi«t-invwtorx Axxdrev Qeninger 



Inventor * a e ignature : ' / ^ / ^^KXy * Sate : 



Residences 15X1 Corta via/ XiOi Altoa, califeoenia 194024 
citixenahip! U«8.A. 



POfiC Office Addreaa: Same 



DSGLftRAXXOH AMD P0998f( Of FOR ^XTXVIT APPZiZCXTXCK 



Page Z ot 2 



Full nam o£ tMrd joiat-i«v«ntor; Mate {»JI> ffafelonski 



Inventor'* »±^atiir«} 




Date: 












Citizenship ; T7. S .X. 


Post Otfice AMresa; ^izoft 










roll nase of fourth :joist-iamK^tQtf ; 9l«ttn X* Kftrcy 








Inventor** aignature; ^i/^ ^^/7 


— ■ 


sat* 




Rasidenae: 2260 Kooastead Ct* fti^Od, X.ob Altoa, California »40a4 

r cL/^ 


Citlzanahip: n.^^x* 


Post office Addi^fiflt SU&fi 


full naiae o£ fifth joint-iavantori Xicteal C» Harto 






Date 




R6eid«&e6s 8674 Calleo Cewtf iftwgan BixXr G«ltfo«al« 








Citizenship; O.S.X. 



poet Office Address; sawa 



PKCXASATXOH AMD POWBR q» MTOWESY FOR FMHK APPLICtttlW 



Paga 1 o£ 3 
SOCXSIt Stf»96505 



AS a below namod inveator, I herd>y declare that: 

My residence, post office address and citizenship are as stated below next to ay name,- 

-r v^n*«o T Atn tlie oriolnal. first and sole iavajxtor (i£ only one name i» liatad below) or 
ii^iSSal, JS^t "^JntSTdf plural axe listed belo*) of the s^ject 

Sich S claimed and for which a patent is songJit on th« Inventxon entitled 

Che specif ioaticm of tdiifih (cheek one) 

_x is attested heireto. 
ms filed on 



ae application Serial Ko. 

and i^s amended on — applicable) . 

I Hereby stete that 1 have reviewed and understand che contwits of the above identified 
^SSfSaSS? ISlui^ ehe deitns. »»«ded by any e«nd»«Lt referred to above. 

JioJenowledse the doty to disclose inforaation which ie waterial to patentability as defined 
|g Title 37, Code of federal Regulation*, section i.ss. 

iQhereby claim foreign priority benefits under Title JS; .J?ite; f J*tej Code, J^^^g ®« 
■Bv^fMeion auolicationts) for patent or inventor's certifieate Ixeted belo*r and have aiao 
lLtSi3^^Si Syfe«ign application for patent or>ttvantor's certif:uc»t. having . 
gl^g date before that of the application on «hich priority is claiaedi 

tiior Foreign application (a) Priority Claimed 

Yea W O 

V (iBer) (Country) (Day/MontW»«r Filed)" 

iihereby claim the benefit under Title 3S, Xfaited States code, section 130 of a^y^^^. _ 
iiS?S^p|licatiS(S) listed below and, ineofar as the aubaect matter of each of^theclaims 

II tSs Spplication is not disclosed, in the prior united states ^^JJ^?!,^ 
Soviied ly the first paragraph of Title 35, uoited states 

Se tb disclose ^orSatlon which is material to P»5«»tability as defined in Title 37, 
Sde of Federal Regulations, section Which /Sf^^^^g^?^ 

prior applicationlnd cue national cr PCT international filing date of this application- 

T applicatiS^lerial Mo.) (Piling Pate) (statue) (patented, pending, abandoned) " 

1 hereby declare that all statetnentc made herein of ay own knowledge are txae that all 
ItS^trSdrcrSfSmatioo and belief are ^^IfY^f ."^.^IrJ^^JTSTlS s^Sde 
statements were made witb the )enowledge that wxllful false atatem^ts and the llXe J»*afi 
arrSSfihable by f±ne or inprisonaieS. or both, under Section lOOl of Title 18 of the 
SitldS^s c3e and thatsuch willful false statements may jeapardize the validity of the 
a)pplicatian or any patent issued thereon. 



XXfiCIAMAZGH AKD POKER O? AnraiHW VOR PASSMff UnzmrXOV DOCKSZs STdd«50S 



POHZR OF ATTWAK; AS a named ixiventOT/ X hereby appoint £9lloirijag attorney (a) and/or 
agent (J) co prosecute this application and transact busineas in the Patent and Trademark 
Office connected therewith, (li&t name and registraticm ausiber) 

i^rilvn Smith Daorffcli^f , &egi«tratioa No^ 31,140 > '^^^i^frgp her a. flucfhes . Regifitration Vo^ 
26 , 914 , David lT, Ratapoa. Registration NO. 34-3S7 . Jtohn B, Hi;^! . Registration »o. 26. 27^ ^ 
p yftjfttiss Jahnson . Regiscraticm Ifo, 32.123 . Rdward A, Pennintfcen , Regiacration Vo. ZZlSSl* 
Jtosepfr C. RedHtoa ; ^. Jr. . Registration No* ifi^J5i^ All of Wiom are attorneys with IRM 
Corporation; and 



George satM, Registration No. SUSSSL* fe-eggyiry- B. wfaftd. Registration Vo. aa. ftaynnga^ 
A. Rocrueaigi. . Regiatratlc»i lao. ;^J,42g . and Tt^CTIiTD Registration No. 2^,24g , all of 

wh^ are attorneys vith the law firm ot Mercbaat, Goulds smith, Sdell, Welter 4k Bdbmi^t 



send eorregprmdefiwe tos Qeorge H. QateSj Ssq. 

Merchant I Gould, Smxth, Sdell, 

Welter & Schmidt 
Suite 400 

iiiso Santa Monica Boulevard 

lioe Angeles, California 50025*3395 



pinct Tel^Qhene Call^ tos (name and telephone nniiber) George K. Gates, (3X0) 44£«ll40 



Jgill navke o£ »bl« or first Joint-inveatmrs Mark s. Saev&a 

l|iwentor's signature: nate^ 



i^ffrsid^nce: 2509 Alpine Road, Ifianle Park, California 94025 

l€iti£enshipj t^^S.A* 

iost Office Address fi Same 



ruU name of second jolnt^iimntor: Andrew 9. Aeninger 



Inventor's signattsrez Date: 

Residences Xfill Corte ^(na, i^s Altoe, California S4024 

Citizenship: 9. 5, A.. 



Post Office Address: ^agae 



V Va^o 3 of 3 

QBCIiftK&KOK aan> POHSR of ATTWdSr for FAT£i«T APPJIiZCKXZOK OOCttXt ST9*fi505 

Full name o£ tblxd jclrLt:-ixi:v«aiu»r£ Kgre (MHI) JabXooaki 




Residence: 332 Waverley Street, Palcu&li»# C&ll£<»niii» 54301^^ 



Citizensbip: 17«9.A« 



^oeC 0£:£iGe Address: Same 



Full xiaaM o£ foiirtu ^lolst^iaaventors <si«zm A. Kaxcy 

Invs^tor's signature: D&te: 

I ^B t" " II ^^^^^^lil ■ Willi I^M>1M^^Wi> II > I " .^IIW—^^^ — Mi^l - W> 

fiesidenca& 22^0 aguff^^^ Ct. #308, Altcw/ C»li£osai» 94024 

" t-J 

/feltiaensl^ip : tt > 3 « A. 

-f.Mt OfClce Address E SggjigL 

fluXl nuM of £i£th joi&t-isvwatters Kichael C. Vttru 

f inventor 'a algnatuxe: Ositei 

l^&xdoncd: 2674 Calico Cowt, llorgu California 95037 

CitizenSllip : U * S « A - 



Podt Office Addsreee: gjfttne 



